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METHOD AND APPARATUS FOR MONITORING TELEPHONE STATUS 

The present application is a continuation-in-part of U.S. Patent Application No. 
09/282,360 filed March 31, 1999. 

BACKGROUND OF THE INVENTION 

Conventional telephone systems can provide a caller's status information, 
but do so in a costly manner that requires significant user time. For example, the 
office based PBX telephone system provides a caller with status information. 

Determining whether the party's line is busy or available requires a caller's 
telephone to poll a central station and wait for a call back to receive status 
information. 

At present, the telephone industry is in the process of switching to digital 
technology (i.e., Integrated Services Digital Network (ISDN), and Asymmetric 
Digital Loop (ASDL)). ISDN is an international communications standard for 
sending voice and data over telephone lines. ISDN technology transmits data at a 
rate far faster than prior telephone connection technologies. ISDN lines generally 
include three channels, two bearer (B) channels and one data (D) channel. Each B 
channel carries voice and data at a bandwidth of 64 kbps (thousands of bits per 
second), and the D channel handles signal control information. ISDN's two B 
channels enable the caller to simultaneously receive and send information. 
Currently, digitally enabled telephones are being produced. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows a schematic diagram of a conventional telephone system. 

FIG. 2 shows a schematic diagram of the digital phone monitoring system 
of an embodiment of the present invention. 

FIG. 3 shows a schematic diagram of a connection between a client 
telephone of an embodiment of the present invention and a telephony application 
programming Interface (TAPI). 

FIG. 4A shows a schematic diagram of a client telephone of an 
embodiment of the present invention. 
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FIG. 4B shows a schematic diagram of a client telephone of another 
embodiment of the present invention. 

FIG. 5 shows a diagram of a central server in accordance with the digital 
phone monitoring system of FIG. 2. 



client telephone. 

FIG. 7A shows an exemplary table of a client database stored on a central 

server. 

FIG. 7B shows an exemplary DTMF code database stored on a central 

server. 

FIG. 8 shows an exemplary TCP/IP information database stored on a 
central server. 

FIG. 9 shows a flowchart of the notification process performed by a central 

server. 

FIG. 10 shows a flowchart of the registration performed by a central server. 
FIG. 1 1 shows a flowchart of the notification process performed by a 
central server. 

FIG. 12 shows a flowchart of the queue manager process performed by a 
central server. 

FIG. 13 shows a diagram of an embodiment of a client telephone. 

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT 

The telephone disclosed in various embodiments of the present invention 
may be configured in accordance with a "plug-and-play" protocol. The user of the 
telephone simply plugs the telephone into a telephone jack. The telephone 
automatically connects to the central server, receives TCP/IP information from the 
server for future communications and registers the client. The client then selects 
the parties that the client wishes to monitor. 

The client may select parties to monitor by programming the parties' 
telephone numbers into the client's local telephone or by a directory lookup by 
name. The client's telephone communicates these telephone numbers to the 
central server and the central server verifies that the parties agree to be monitored. 



FIG. 6 shows an exemplary table of a monitored party database stored on a 
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Once the parties agree, the parties register with the system. The client may also 
select parties to monitor by contacting the service associated with the central server 
off-line and submitting a request to monitor the specified parties. The central 
service may verify the agreement of the parties to be monitored by contacting them 
off-line (e.g., via telephone call, postal mail, e-mail). 

Alternatively, the process to select parties to monitor may be initiated by 
the monitored party. The party to be monitored submits a request to the central 
server. In return, the central server remotely programs the monitoring party's 
telephone with the monitored party's status and identification information. It will 
be appreciated that the monitoring party may locally program its telephone. If the 
monitored party requests a monitoring party that is currently not a client to the 
status monitoring service, the service contacts the monitoring party off-line to 
determine if this party wishes to become a client to the service to receive status 
updates from the monitored party. 

Referring first to FIG. 2, a schematic diagram of the digital phone 
monitoring system of an embodiment of the present invention may be generally 
appreciated. It will be appreciated that an embodiment of the present invention 
defines a first telephone as a monitored client telephone 202, and defines a second 
telephone as a monitoring telephone 206. In particular, communication links 
between three monitoring client telephones 206, a central server 204 and three 
monitored client telephones 202 are shown in FIG. 2. Whenever a change in status 
of a monitored client telephone 202 occurs, monitored client telephone 202 
communicates the status change via central server 204 to each monitoring client 
telephone 206 registered to receive status updates of that monitored client 
telephone 202. It will be appreciated that the number of monitored client 
telephones 202 and monitoring client telephone 206 shown in FIG. 2 were 
arbitrarily chosen, and that alternative embodiments of the present invention may 
include any number of monitored and any number of monitoring client telephones. 

One of ordinary skill in the art will understand the benefits of receiving the 
status of another telephone. For example, teenagers may monitor their friends to 
determine which of their friends' phone lines are busy. When a teenager wants to 
call a friend, prior to even picking up and dialing the phone, the teenager 
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automatically knows which friends are available to talk. The teenager may be 
presented with a list of friends, so that the teenager can instantly see which ones 
are available. In another example, a mother may want to monitor her home 
telephone while at work. The mother may be interested in determining whether the 
phone is busy, or may wish to monitor the amount of time that her son, daughter or 
babysitter is on the phone per day. 

It will also be appreciated that status information may be input at monitored 
client telephone 202. For example, when a child arrives home, the child may enter 
a DTMF code into monitored client telephone 202 (e.g., *68). The code 
representing a status update is sent to central server 204. Central server 204 
forwards the status information to the child's mother's monitoring client telephone 
206, thereby informing the mother that her child has arrived at home. 



employeeVr consultant is working. For instance, the employee or consultant 
enters a preo^termined code into monitored client telephone 202 when arriving at 
work. Monitored client telephone 202 sends the code to central server 204. 
Central server 204 searches a DTMF code database 340, as shown in FIG. 7B, 
retrieving the statusVorresponding to the code. Once retrieved, central server 204 
sends the status to monitoring client telephone 206. The status allows the 
supervisor to know when\to contact the employee or consultant. Alternatively, this 
embodiment of the invention may provide the supervisor with additional 
information. For example, accounting and billing processes may calculate the total 
number of hours the employee worked. The status may also affect the billing rate 
for the called party. For example, calling a consultant while her status is 
"unavailable" may result in a higher charge (e.g., a higher hourly billing rate) for 
that caked time. A billing program may obtain such information as total time with 
a certain status (e.g., a status of "working") ahd/or the total time on the phone with 
a particular status (e.g., "lunchtime") and / or thexapplicable billing rate or other fee 
structure. Such a billing program could then generate an appropriate bill based 
thereon, and output a bill in printed, electronic file, errM, fax or other forms. 
Those skilled in the art will recognize that these examplesVre provided purely for 



another example, a supervisor may monitor when a telecommuting 
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illustrative purposes and should not be understood to limit the breadth of the 
invention^ 

^tatus information may also be automatically determined by client 
telephone *02, central server 204, a monitoring client telephone, or any 
combination of the foregoing whether cooperating or not. For example, the 
location or approximate location of a phone (e.g., a cellular phone with GPS 
capability, cellular^hones with other location abilities, calculating the Doppler 
effect of a signal received from a cellular phone) may be ascertained by the central 
server 204 by, e.g., receiving a signal from the cellular phone that indicates the 
location or approximate location of the cell phone. Alternatively, the phone may 
broadcast a signal, which is rebeived by a receiver. The strength and / or time of 
reception of the signal may allow>the central server to determine the distance of the 
phone from the receiver. The mere tact that a signal is received may also indicate 
the location of the phone. In certain embodiment, a low strength receiver that 
receives a signal, or a receiver that received a signal from a low power transmitter, 
may indicate that the transmitter is within a cVtain area. For example, a base unit 
may be equipped to receive a signal from a hana^et unit only if the handset is 
within one hundred feet of the base. In another exaW>le, a base unit may readily 
determine when the handset is physically plugged into t^e base. 

It is additionally possible to use a plurality of such receivers to more 
accurately determine the location of the phone through known locating techniques, 
including but not limited to triangulation. Referring now to FIG. 3, a diagram of a 
Telephony Application Programming Interface (TAPI) 332 connected to 
monitoring client telephone 206, monitored client telephone 202 and central server 
204 may be generally appreciated. Those of ordinary skill in the art will readily 
contemplate, based on the present disclosure, other interfaces besides the specific 
TAPI illustrated in FIG. 3. Central server 204 includes a plurality of 
communication applications 302 such as a call control application 304, an 
interactive voice application 306, a voice mail application 308, a call center 
application 310, and a TCP/IP conferencing application 312. Central server 204 
also includes a registration service 314, a notification service 316, an 
encryption/decryption service 318, a queue manager 320, a start-up/self test service 
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322, a monitoring service 324, a TCP/IP database 326, a client database 328, a 
digital signature 336, a call accounting service 338 and a DTMF code database 
340. A TAPI interface 330 connects each of the above components to TAPI 332. 
A detailed description of the services, managers, and databases in conjunction with 
FIG. 5 will be provided below. 

As shown, TAPI 332 enables applications to access all the telephony 
options available on any machine. For example, the communication applications 
302 including call control application 304, interactive voice application 306, voice 
mail application 308, call center application 310 and TCP/IP conferencing 
application 312 may access all telephony options available on monitoring 
telephone 206 and monitored client telephone 202. For instance, the applications 
may access monitored client database 334 stored on monitoring client telephone 



The data on a call is available to applications in a standard manner. TAPI 
332 is an architecture that provides simple and generic methods for making 
connections between two or more machines and provides each machine access to 
any media stream involved in that connection. TAPI 332 abstracts call-control 
functionality to provide a common interface to applications that utilize different 
and seemingly incompatible communication protocols. This interface connects 
monitored client telephone 202 and monitoring client telephone 206 to central 
server 204. 

Referring now to FIG. 4A, a diagram of a client telephone 400 of an 
embodiment of the present invention may be better appreciated. One of ordinary 
skill in the art will recognize that client telephone 400 may comprise either a 
monitoring client telephone 206 or a monitored client telephone 202. Client 
telephone 400 may be implemented as one or more separate devices. For example, 
client telephone 400 may be a single device or comprise a combination such as a 
telephone in communication with a separate sensor input device which is itself in 
communication with a separate transmitter device. Many more variations are 
contemplated by the present disclosure. 



Client telephone 400 operates under a multi-tasking, multithreaded 
operating system platform (e.g., UNIX, or WINDOWS NT by MICROSOFT of 
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Redmond, Washington). As shown, client telephone 400 includes a display device 
402, an input device 405, a processor 404 and a data storage device 407. Processor 
404 is connected to a communication port 406 (e.g., network interface). 

Input deiuce 405 may comprise a keyboard comprising a plurality of 
DTMF coded buttons. Alternatively or in addition, input device 405 may comprise 
a means for receivingsother types of input. For example, input device 405 may 
comprise a GPS receiveV for receiving information from a global positioning 
system. Such a GPS receiW typically receives broadcast signals that allow it to 
determine latitude, iongitudeSaltitude, and time. Similarly, input device 405 may 
comprise a receiver that receive\yarious wireless signals such as radio signals or 
infrared signals. Such receivers may be capable of receiving signals transmitted by 
cell phones, appliance remote controls\such a s television remote controls, remote 
car lock actuators, remote garage door openers, PDAs, and other devices. 

Input device 405 may comprise sensors or detectors that detect stimulus 
such as motion sensors (whether based on Doppler effects or other types of motion 
sensors), sensors that measure movement or actuation of a door or garage door; 
electrical sensors that detect activation or deactivation of air conditioners, lights 
and other devices; general electrical sensors that detect power consumption; weight 
sensors; temperature sensors; and combinations and equivalents thereof. 

Input device 405 may comprise means for detecting the powering up or 
activation of the client telephone 400. For example, the input device 405 may 
comprise a detector in communication with a circuit that activates or powers up a 
device, component of a device or plurality of components of a device. 
Accordingly, input device 405 may comprise means for detecting the powering up 
or activation of (i) a telephone, such as a desktop phone, cellular phone or wireless 
phone; (ii) a computer; or (iii) a television. 

Input device 405 may comprise a microphone or other audio reception 
device, possibly but not necessarily separate from the conventional microphone of 
a telephone for receiving spoken sounds. Such a microphone can be operational to 
detect, process and / or transmit sound even if the phone is in an inactive state, 
such as when it is not in use or when a receiver is cradled. 
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Display device 402 is an LCD or other type of display that shows the status 
of each party being monitored by client telephone 400, in accordance with the data 
stored in monitored client database 334. For example, the display shows a name 
and the current status of each party being monitored. It will be appreciated that 
client telephone 400 might not include display device 402. 

Communications port 406 provides the network interface to central server 
204 using TCP/IP over the D channel on an ISDN telephone line. One of ordinary 
skill in the art will recognize that the telecommunication specifications are 
provided purely for illustrative purposes and that alternative embodiments of this 
invention may include different telecommunication methods. 

Data storage device 407 includes a monitoring service 324 that processor 
404 executes to provide client digital phone 400 with monitoring functionality. 
Data storage device 407 also includes a startup/self-test service 410, display 
manager 412, digital signature 414, encryption/decryption service 416, monitored 
client database 334, call accounting service 418, a TAPI interface 420, a 
communications applications 422, a registration service 424, a queue manager 426, 
a DTMF code database 428, and a notification service 430. The communications 
applications 422, the registration service 424, the queue manager 426, the DTMF 
code database 428, and the notification service 430 are utilized by the client 
telephone 400 in ways similar to those of the corresponding elements of the central 
server 204, as described below. 

Startup/self-test service 410, at startup, tests all hardware of client 
telephone 400 and loads the operating system and services. If connected via TAPI 
interface 420 to central server 204, startup occurs when client telephone 400 is 
powered on. A startup may also occur if a user presses a re-boot key (not shown) 
located on client telephone 400. Startup/self-test process 410 typically includes 
three types of tests. It performs a checksum on EPROM, checks the ISDN line to 
confirm that the link with central server 204 on D and both B channels is up and 
running, and confirms that a "service provider identification" (SPED) matches the 
SPID pre-programmed on client telephone 400. A SPID is typically composed of 
the telephone number of client telephone 400 followed by four additional digits. It 
will be appreciated that central server 204 assigns client telephone 400 TCP/IP 
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information during the initial connection between client telephone 400 and central 
server 204, and client telephone 400 subsequently stores that information. It will 
also be appreciated that, at startup, client telephone 400 sends its TCP/IP 
information to central server 204, and central server 204 verifies that the TCP/IP 
information matches the assigned TCP/IP information of client telephone 400. 
One of ordinary skill in the art will understand that in addition to ISDN, 
startup/self-test service 410 may be applied to other types of communication 
technology. 

If client telephone 400 is a monitoring client telephone 206, after 
startup/self- test service 410 is executed by processor 404, monitoring client 
telephone 206 requests that central server 204 send status updates of the monitored 
client telephones 202 that it is authorized to receive. Monitoring client telephone 
206 seizes the D channel of the ISDN line and sends its DTMF codes. Central 
server 204 reads the registration information and routes the call to registration 
service 314 via a communications (e.g., a DS-1 or DS-3) line. One of ordinary 
skill in the art will recognize that the demand for communication lines at the time 
central server 204 transmits the code information determines which line is chosen. 
Registration service 314 senses the incoming call and causes central server 204 to 
go off-hook on that line. Once off-hook, registration service 314 opens a 
communication link between central server 204 and monitoring client telephone 



Once monitoring client telephone 206 senses that the D channel 
communication link with central server 204 is established, it builds and encrypts an 
acknowledgment message with its SPED and a digital signature. 
Encryption/decryption service 416 of monitoring client telephone 206 uses the 
public key of central server 204 to encrypt a message and generate a digital 
signature bundled with the message. Encryption/decryption service 318 of central 
server 204 uses the private key of central server 204 to decrypt the message and 
validate the signature. The digital signature provides the security clearance of 
monitoring client telephone's 206 identity. 

If encryption/decryption service 318 of central server 204 successfully 
decrypts the message and verifies the digital signature of monitoring client 
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telephone 206, central server 204 sends an acknowledgment (ACK) message and 
its digital signature back to monitoring client telephone 206. If the verification 
fails, server 204 instead sends a no-acknowledgment (NAK) and its digital 
signature back to monitoring client telephone 206 and drops the line. If monitoring 
client telephone 206 receives an ACK, it verifies the digital signature of central 
server 204. If the verification is a success, monitoring client telephone 206 returns 
an ACK message to server 204. If the verification fails, monitoring client 
telephone 206 returns a NAK message to server 204 and drops the line. If the 
communications between central server 204 and monitoring client telephone 206 
resulted in ACKs, a session is established between monitoring client telephone 206 
and registration service 314 of central server 204. 

Registration service 314 queries client database 328 to confirm that the 
account of monitoring client telephone 206 is in good standing. Although not 
shown, a preferred embodiment of client database 328 may include client billing 
and account information. It will be appreciated that the telephone company will 
typically provide the status monitoring service only to clients that have paid their 
telephone bills. Registration service 314 then sends a clear to send (CTS) message 
to monitoring client telephone 206 that it is ready and waiting. Monitoring client 
telephone* 206 receives the message and creates and sends a monitor message 
(MM) to registration service 314; Registration service 314 receives the message 
and queries client database 328 to obtain the current status of the monitored client 
telephones 202 that monitoring client telephone 206 is authorized to receive. 
Alternatively, the message from monitoring client telephone 206 may include a 
request for a status update of specific monitored client telephones 206. 

After entering the appropriate status information into a message, 
registration service 314 uses the public key of monitoring client telephone 206 to 
encrypt the message, and return the message. Monitoring client telephone 206 
receives the message and decrypts it with its private key. 

Monitoring client telephone 206 then updates monitored client database 
334 and outputs the status of each party. Monitoring client telephone 206 then 
sends a message to registration service 314 of central server 204 acknowledging 
successful receipt of the status updates. Call accounting service 338 updates client 
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database 328 to bill for the successful inquiry and drops the session by clearing the 
channel. Monitoring client telephone 206 recognizes that the channel is down and 
enters into a wait state until notification service 316 sends it updated status 
information. One of ordinary skill in the art will recognize that once monitoring 
client telephone 206 restarts and resets with status updates of monitored client 
telephones 202, monitoring client telephone 206 begins to automatically receive 
status updates without the need to poll central server 204. 

Monitored client database 334 includes monitoring information stored on 
storage device 407 of client telephone 400. See FIG. 6 for an exemplary view of 
monitored client database 334. As shown, the monitoring information includes 
monitored client SPID 602, monitored client name 604 and status 606 of the 
monitored client. It will be appreciated that alternative embodiments of this 
invention may include other varied types of monitoring information. For example, 
monitored client database 334 may also include information such as total number 
of hours a monitored phone is busy, or total number of hours that a monitored 
telephone of an employee had an associated status of "working". 

Display manager 412 accesses monitored client database 334, and displays 
this information on display device 402 of client telephone 400 (if display is the 
method of outputting status). Display manager 412 may also display messages 
originating from central server 204. For example, display manager 412 may 
receive and display messages from central server 204 during registration of client 
telephone 400. 

Digital signature 414 provides client digital telephone 400 with the ability 
to verify the identity of a sender of TCP/IP message packets by creating and 
utilizing private and public keys. Digital signature 414 is included with encrypted 
messages sent between client telephone 400 and central server 204. At client 
telephone 400, the recipient's public key is used to encrypt a message and generate 
a digital signature string that is bundled therein. Upon receipt of the message, the 
recipient, such as central server 204 or another client telephone 400, uses its 
private key to decrypt the message and validate the signature. Validating the 
signature verifies the message sender's identity. 
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Call accounting service 418 on client telephone 400 maintains up-to-date 
billing information. For example, call accounting service 338 of central server 204 
sends telephone usage and billing updates to client's telephone 400 and stores the 
updates on storage device 407. In response to a subscriber's request, display 
manager 412 accesses and displays the information on display device 402. It will 
be appreciated that central server 204, in an embodiment of this invention, 
routinely initiates the transmission of accounting information to call accounting 
service 418. In still another embodiment, call accounting central service 418 
retrieves telephone usage and billing updates from central server 204 in response to 
a request from the subscriber of client telephone 400. 

FIG. 4B illustrates an embodiment of client telephone 400. A phone 450 is 
in communication via wire or wireless medium with a peripheral 455, which is in 
turn in communication via wire or wireless medium with a display 460. Display 
460 may comprise any device for presenting information visually, such as an LCD 
(liquid crystal display), monitor, or similar device. The functionality of the 
embodiments of the present invention may be distributed among the phone 450, 
peripheral 455 and display 460 in an appropriate manner as would be apparent to 
one of ordinary skill in the art. For example, peripheral 455 may comprise a 
computer or similar computing device. 

A communication device 465 permits the phone 450 to transmit and receive 
signals. Communication device 465 may comprise means for transmitting and 
receiving data over a cable, wire or similar medium, as might be appropriate for a 
desktop phone. Alternatively, communication device 465 may comprise means for 
transmitting and receiving data wirelessly via infrared, radio or similar signals, as 
might be appropriate for a cellular phone or other wireless device. In one 
embodiment, peripheral 455 and display 460 may compose an integral unit which 
is adapted to be connected to phone 450. For example, an integral unit may 
comprise a single casing which encloses therein the peripheral 455 and the display 
460, while the casing defines an opening allowing a portion on the viewable area 
of the display to be seen outside the casing. 

Such an integral unit, or at least one of the individual peripheral and 
display, may be fitted to the phone 450 and detachably held thereto by the shape of 
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the integral unit relative to the phone 450. Alternatively, fitting to the phone 
detachably holding thereto may be accomplished by a fixing means such as a snap 
or similar means. Physical contact need not be required for communication 
between the phone 450 and the peripheral 455. 

Referring now to FIG. 5, a diagram of central server 204 may be better 
appreciated. Central server 204 operates under a multi-tasking, multithreaded 
operating system platform (e.g., UNIX, or WINDOWS NT by MICROSOFT of 
Redmond, Washington). As shown, central server 204 includes an input device 
502 (e.g., CD ROM or floppy disk drive, keyboard), processor 504 connected to a 
communications port 506, and a storage device 507. Communications port 506 
provides a network interface, using TCP/IP over the D channel on an ISDN 
telephone line to connect central server 204 to monitored client telephone 202 and 
to monitoring client telephone 206. One of ordinary skill in the art will recognize 
that the telecommunication specifications are provided purely for illustrative 
purposes, and that alternative embodiments of this invention may include different 
types of telecommunication methods. 

Storage device 507 includes monitoring service 324, TAPI interface 330, 
encryption/decryption service 318, start-up/self-test service 322, queue manager 
320, notification service 316, registration service 314, client database 328, TCP/IP 
information database 326, communication applications 302, call accounting service 
338, digital signature 336 and DTMF code database 340. Monitoring service 324 
provides central server 204 with a monitoring process in accordance with various 
embodiments of the present invention. TAPI interface 330, as discussed above, 
enables applications, such as monitoring service 324, to access all the telephony 
options available on any client telephone. For example, it provides monitoring 
service 324 with access to updated monitored client database 324 stored on client 
telephone 400. 

Encryption/decryption service 318 employs private and public keys to 
respectively decrypt and encrypt messages that are sent to client telephone 400. 
This process also employs a digital signature 336 to verify the message sender's 
identity. Central server 204 receives a digital string encrypted with a message 
from client telephone 400. Upon receipt of the message, central server 204 uses its 



13 



02-004 AP as filed 03.05.02 




10090795 .-030502 



Express M^Hno. EV013984440US 
Attorney Docket No. 02-004 



private key to decrypt the message and validate digital signature 336. Similarly, 
when central server 204 sends a message to client telephone 400, central server 
204 utilizes the public key of client telephone 400 to encrypt the message and 
generate a digital signature string that is bundled therein. Client telephone 400 
uses its private key to decrypt the message and validate the server's identity. 

Startup/self-test service 322 initializes all components at startup and checks 
predetermined parameters when booting up. Tests include confirming that the 
ISDN line over D and both B channels that connect central server 204 and client 
telephones 400 is operating within predetermined parameters, and verifying that 
incoming messages to central server 204 are originated from authorized SPEDs. 
For example, at startup, startup/self-test service 410 of client telephone 400 sends a 
SPID verification message to central server 204. Startup/self-test service 322 of 
central server 204 verifies that the SPID is authorized to receive monitoring 
information. 

Registration service 314 registers monitored client telephones 202 and 
monitoring client telephones 206, and maintains a list of current accounts and a list 
of the active connections between subscribers. Registration service 314 stores the 
list of current accounts on client database 328 and stores the list of active 
connections on TCP/IP information database 326. FIG. 7 shows an example of 
client database 328, and FIG. 8 shows an example of TCP/IP information database 
326. 

If the status of monitored client telephone 202 changes, notification service 
316 receives a status information update. Notification service 316 notifies queue 
manager 320 to transmit the status update to the appropriate monitoring client 
telephones 206. Queue manager 320 receives notification of the status change 
from notification service 316, queries client database 328 for the appropriate 
SPID(s) to contact, and transmits an indication of the change in status to the 
authorized clients designated by the appropriate SPID(s). 

Call accounting service 338 maintains and sends billing information in real 
time to each client. More particularly, call accounting service 338 sends 
accounting and billing information in update packets to the client's telephone 
either (i) periodically (e.g., daily), or (2) in response to a client request. 
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Accordingly, a client can always view in real time the specific charges associated 
with a call or view the running total for monthly bill. It will be appreciated that 
call accounting service 418 employed by client telephone 400 provides a 
subscriber with numerous functions for viewing and processing specific charges. 

Referring now to FIG. 6, a diagram of an exemplary monitored client 
database 334 stored within monitoring client telephone 206 may be better 
appreciated. As shown, each entry of monitored client database 334 specifies a 
monitored client telephone 202 that is assigned to send status information to a 
monitoring client telephone 206. In an exemplary embodiment of the present 
invention, monitored client database 334 includes, for each party being monitored, 
a monitored client SPED 602, a monitored client name 604, and the current status 
606 of monitored client telephone 202. It will be appreciated that for a given 
monitored client SPED 602, monitoring client telephone 206 may monitor more 
than one status. For example, the last entry 607 of monitored client database 334 
includes more than one status. 

A number of methods are available to enter data into monitored client 
database 334. For example, in one method, a client using input device 405 locally 
inputs monitored client SPIDs 602, and corresponding monitored client names 604 
into monitored client database 334. In an alternative method, central server 204, in 
response to a request from monitoring client telephone 206, remotely updates the 
SPIDs of monitored client database 334. 

A client requests status monitoring by either calling a telephone company's 
toll-free number to verbally request monitoring, or by electronically submitting a 
request via an Interactive Voice Response (IVR) unit. It will be appreciated that a 
Voice Response Unit (VRU) may also be used. However, before monitoring of a 
particular SPED occurs, central server 204 must receive permission from the party 
at monitored client telephone 202. The central telephone office requests 
permission by electronically sending a request via central server 204 to monitored 
client telephone 202, or by contacting the party using another method. Other 
methods may include, for example, a telephone call, an e-mail, or a letter. If 
central server 204 receives permission, it sends an authorizing signal to monitoring 
client telephone 206. Once authorized, monitoring client telephone 206 receives 
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status updates from central server 204, and enters the updates into monitored party 
database 334. Display device 402 of the monitoring client telephone 206 displays 
each status update 606. 

Alternatively, monitored client telephone 202 may initiate the request to be 
monitored by monitoring client telephone 206. When central server 204 
electronically receives the request, or the central telephone service receives the 
request using another manner, the service requests permission to send monitoring 
client telephone 206 status updates of monitored client telephone 202. As 
discussed above, the request for permission may be electronically submitted by 
central server 204 or provided using another manner. 

It will be appreciated that a subscriber at monitoring client telephone 206 
may monitor a status change of a particular predetermined condition. For example, 
a subscriber may choose to monitor the "bus/' status of monitored client telephone 
202. Alternatively, a subscriber may choose to monitor when the person at 
monitored client telephone 202 enters a DTMF code indicative of a working status. 
One of ordinary skill in the art will recognize that these examples are purely 
illustrative of different status changes, and that alternative embodiments of the 
present invention may include status changes of other predetermined conditions. 

Referring now to FIG. 7(A), a diagram of an exemplary client database 328 
stored on central server 204 may be better appreciated. As shown, this database 
includes entries for each monitored client telephone 202 that is registered with 
central server 204. Each entry includes the party being monitored, identifiable by 
monitored client SPID 702, the party receiving the status updates, identifiable by 
monitoring client SPID 704, and the particular status changes monitoring client 
telephone 206 will receive, shown as monitored status 706 and a current status 708. 
It will be appreciated that the current status 708 of an entry of client database 328 
may include more than one status. The process of updating and maintaining client 
database 328 will be discussed in conjunction with the description of the 
registration process shown in FIG. 9. 

Referring now to FIG. 7(B), a diagram of exemplary DTMF code database 
340 stored at central server 204 may be better appreciated. As shown, this 
database includes a status 714 assigned to each DTMF code 712. Notification 



16 



02-004 AP as filed 03.05.02 





service 316 of central server 204 uses DTMF code database 710 to translate 
incoming DTMF codes to an appropriate status. It will be appreciated that a 
DTMF code may represent information other than a status. For example, a DTMF 
code may represent a request for billing information. 

Referring now to FIG. 8, a diagram of exemplary TCP/IP information 
database 326 stored at central server 204 may be better appreciated. As shown, 
this database includes entries for each client telephone 400 registered with central 
server 204. Each entry includes a SPID address 802 and a corresponding TCP/IP 
address 804. A TCP/IP address information 804 is issued to each client telephone 
400 registered with central server 204. It will be appreciated that central server 
204 communicates with other nodes and clients based on their assigned TCP/IP 
address 804. One of ordinary skill in the art will recognize that the header portion 
of messages sent between monitored and monitoring client telephones 400 and 
central server 204 typically include a TCP/IP address 804. When receiving or 
sending a message, central server 204 uses the SPED address 802 listed in the 
TCP/IP database 326 to verify that the TCP/IP address included within the 
message's header portion is correct. 

Referring now to FIG. 9., a flowchart of a status monitoring process 900 
may be generally appreciated. As shown, in step 902, central server 204 registers 
the subscriber of monitoring client telephone 206. In step 904, the subscriber of 
monitoring client telephone 206 selects the parties the subscriber wishes to 
monitor. In step 906, central server 204 registers the parties to be monitored. It 
will be appreciated that prior to registering these parties, central server 204 may 
request each party's permission to be monitored by the subscriber of monitoring 
client telephone 206. In step 908, central server 204 receives TCP/IP packets from 
monitored client telephone 202. In step 910, central server 204 transmits the 
TCP/IP packets to the monitoring client telephone 202 configured to receive the 
status updates. Once received, monitoring client telephone 206 displays the status 
to the subscriber. One of ordinary skill in the art will recognize that FIG. 9 shows 
the general steps of an embodiment of the present invention, and that Figs. 10-12 
described below will explain each step in greater detail. 
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It will be appreciated that in alternative embodiments of the present 
invention, monitored client telephone 202 may register prior to monitoring client 
telephone 206. Furthermore, monitored client telephone 202 may select the parties 
that it wishes to provide status updates. Prior to sending the status updates, 
monitoring client telephone 206 must register and provide central server 204 of the 
central telephone permission to receive the status information. 

When a party at a client telephone 400 wishes to register as a subscriber of 
a monitored client telephone 202 in step 906, or as a monitoring client telephone 
306 in step 902, client telephone 400 seizes the D channel of the ISDN line and 
sends the registration information to central server 204 of a telephone station's 
central office. Central server 204 reads the registration information and routes the 
call to registration service 314 via a DS-1 or DS-3 line. One of ordinary skill in 
the art will recognize that the demand for communication lines at the time central 
server 204 transmits the code information determines which line is chosen. 
Registration service 314 senses the incoming call and central server 204 goes off- 
hook on that line. Once off-hook, registration service 314 opens a communication 
link between central server 204 and the party wishing to register. 

The request for a party's permission to be monitored by the subscriber may 
be accomplished in a variety of ways. The party may affirmatively register his 
willingness to be monitored, whether or not a request for permission has been 
directed to him. Accordingly, a subscriber need not select parties to monitor - the 
parties may indicate that they are to be monitored. 

For example, the party may enter an indication of one or more subscribers 
that are authorized to monitor the party. Such an indication may be entered via a 
phone, for example, by actuating numeric keys (e.g., oh input device 405) to 
indicate the phone number of such authorized subscribers. Such an indication may 
also be entered via a phone, for example, by communicating with a VRU (Voice 
Response Unit). Such a method of entry could be performed via any public or 
private phone, whether or not the that phone had other capabilities described 
herein. An indication of one or more subscribers that are authorized to monitor the 
party may be entered via a computer communicating with a web site, which in turn 
provides the information to, e.g., central server 204. 
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The indication of subscribers that are authorized to monitor the party may 
be made automatically without much or any input from the party. For example, the 
party may set or accept a threshold such that people the party calls (or people that 
call the party) more than the threshold are authorized to monitor the party. 

Many other methods of entry, and many other types of devices used in such 
entry, will be apparent to those of ordinary skill in the art. 

A list of one or more subscribers that are authorized to monitor the party 
may be stored locally on the party's phone or other device and / or stored remotely 
on central server 204. 

Various parties may be authorized to monitor only certain kinds of statuses 
of a particular monitored party. For example, a first group may be authorized to 
monitor all statuses of a particular party, while a second group may be authorized 
to monitor only certain statuses of that party. In another embodiment, various 
parties may be able to attain different levels of access by paying. For example, 
telemarketers and other businesses may be able to pay to ascertain certain statuses 
of a party. The status of a monitored party may be employed as a "block" 
against certain calls. In certain embodiments, it is not necessary for a monitoring 
party to register at all. The block applies to certain callers or all callers, 
irrespective of whether any party registered in any way to receive status. In one 
embodiment, a status may simply indicate that no calls are allowed to get through 
to the monitored party (i.e. all calls blocked). In another embodiment, a status may 
indicate that only certain people are blocked, or that only certain people are 
unblocked (i.e. may call). 

hi some embodiments, certain parties may be allowed to always get 
through a block. For example, it may be desirable for the monitored party to 
always permit\spouse and parent to circumvent a block. In always granting such 
parties access, their phones could be always granted access to the monitored party 
(e.g., by receiving an\dentifying signal (e.g., ANI, SPID) from such phone and 
comparing that signal wkh a list of authorized phones), or those parties could be 
provided with special access codes. Upon calling the monitored party when a 
block is in effect, the party wovrid enter the access code and be granted access by 
allowing there call to get through\ 
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A monitoring party that attempts to call the monitored party but is 
"blocked" may, e.g., receive a busy signal, receive a particular kind of busy signal, 
or receive a particular audio message. 

Certain locations or certain times may be marked as "blocked", thereby 
preventing some or all calls from going through. For example, from a phone 
which has a location that may be determined, a party may enter a code that 
indicates the current location as a "blocked" location or a location where a certain 
status is to be established. For example, a party may enter an office building and 
enter a code via a wireless phone. This could establish a status of "unavailable" 
while the party is in the building. 

The location of the phone upon entry of the code may be determined, such 
that, e.g., that location alone is an area in which the status would be established as 
"unavailable". Optionally, a radius may be set such that when the phone is within 
the radius of that location the status would be established as "unavailable". Such a 
radius may be predetermined, or alterable (e.g., by the party). 

As described herein, once the status changes, for example, if a party moves 
out of an office building previously marked as having a status of "unavailable", an 
email, message or other transmission may be automatically sent to monitoring 
parties. 

In one embodiment, a group of certain parties may be established, and a 
member of the group may determine who in the group is calling another, and who 
is free. The identity of those called by other group members may or may not be 
made available. 

In certain embodiments, establishing such a group can allow a member of 
the group to sort a list of the other members in order of, e.g., frequency of calls to 
the parties, frequency of calls from the parties, frequency of calls to or from the 
parties and / or frequency of calls from the parties to any member of the group. 

In certain embodiments, it can be advantageous to rate members of the 
group based on, e.g., calls with others, calls to other customers on the phone 
network provider (e.g., Verizon) or calls with other members of the group. The 
rating may be based on, e.g., number of such calls, duration of such calls. A rating 
according to this embodiment may confer rewards such as discounted or free 
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products, discounted or free services from the phone network provider. The rank 
may be displayed or otherwise made known to member of the group, conferring 
psychological rewards or penalties upon members. 

In one embodiment, a group of members may eavesdrop on other members 
who are communicating with one another via, e.g., voice, text messaging. Such 
eavesdropping may be automatically allowed, or may require permission from 
those engaged in communicating. It may also be advantageous to allow members 
of the group to access a "log" of prior communication (e.g., recorded voice, 
recorded text messages) to allow eavesdropper to catch up on what had been 
communicating prior to eavesdropping. 

Referring now to FIG. 10, the registration process performed by 
registration service 314 of central server 204 may be better appreciated. In step 
1002, registration service 314 receives a request from a registering client telephone 
400 for a TCP/IP address and a security clearance. The security clearance process 
utilizes a digital signature and encryption to secure the messages sent between 
client telephone 400 and central server 204. More particularly, once client 
telephone 400 senses that the D channel communication link with central server 
204 is established, it builds and encrypts an acknowledgment message with its 
SPID and a digital signature. 

Client Telephone 400 uses a public key of central server 204 to encrypt a 
message and generate a digital signature bundled with the message. The recipient 
of the message uses its private key to decrypt the message and validate the 
signature. The digital signature provides the security clearance of the message 
sender's identity. It will be appreciated that all communications between central 
server 204 and client telephone are encrypted and include a digital signature. 

At registration, if encryption/decryption service 318 decrypts the message 
and verifies the digital signature of client telephone 400, central server 204 sends 
an acknowledgment (ACK) message and its digital signature back to client 
telephone 400. If the verification fails, central server 204 instead sends a no- 
acknowledgment (NAK) and its digital signature back to client telephone 400 and 
drops the line. If client telephone 400 receives an ACK, it verifies the digital 
signature of central server 204. If the verification is a success, client telephone 400 
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returns an ACK message to central server 204. If the verification fails, client 
telephone 400 returns a NAK message to central server 204 and drops the line. If 
these communications resulted in ACKs, a session is established between client 
telephone 400 and registration service 314 of central server 204. 

In step 1004, registration service 314 receives a SPDD/MAC (Media Access 
Control Layer) address from registering client telephone 400. It will be 
appreciated that the SPID/MAC was either pre-programmed into registering client 
telephone 400 or was previously assigned by central server 204. In step 1006, 
registration service 314 checks the SPDD/MAC format. In step 1008, if the format 
is incorrect, registration service 314 sends an "unable to process request" message 
to client telephone 400. If the format is correct, in step 1010, registration service 
314 issues client telephone 400 a TCP/IP address. 

In step 1012, registration service 314 stores the SPED of client telephone 
400 into the appropriate field of client database 522. If client telephone 400 is a 
monitored client telephone 202, registration service 314 stores the SPED as a 
monitored client SPED 702. If client telephone 400 is a monitoring client 
telephone 206, registration service 314 stores the SPID as a monitoring client SPED 
704. In step 1014, registration service 314 stores the SPED address and the 
corresponding TCP/IP address in TCP/IP address database 326. Once client 
database 328 and TCP/IP address database 326 are updated, registration service 
314 sends a registration acknowledgment message back to client telephone 400 
indicating that it is now registered. 

After client telephone 400 registers as a monitoring client telephone 206, in 
step 904, the subscriber of client telephone 400 selects one or more parties that the 
subscriber wishes to monitor. At monitoring client telephone 206, the subscriber 
may enter each parties' phone number into monitored client database 334, where 
each parties phone number is mapped to a SPED. Once entered, monitoring client 
telephone 206 sends these telephone numbers to registration service 314. 
Alternatively, the subscriber may also select parties to monitor by contacting the 
service associated with registration service 314 off-line, and submitting a request 
to monitor the specified parties. 



22 



02-004 AP as filed 03.05.02 





Once registration service 314 receives the request to monitor one or more 
parties, registration service 314 verifies that the parties agree to be monitored. If a 
party is a current subscriber of the status monitoring service, registration service 
314 of central server 204 may electronically send the permission request directly to 
that party's client telephone 400. Alternatively, if a party is not a current 
subscriber, the central service may verify that the party agrees to be monitored by 
contacting that person off-line (e.g., via telephone call, postal mail, e-mail). 

If the party agrees to be monitored by the subscriber of monitoring client 
telephone 206, in step 906, registration service 314 registers the monitored party 
which the subscriber selected. It will be appreciated that if the party agrees to be 
monitored and does not currently included as an entry within the TCP/IP 
information database 326 of central server 204, registration service 314 registers 
this party by performing the steps of the registration process described above and 
shown in FIG. 10. For all monitored parties, registration service 314 updates client 
database 328 with each party's monitored client SPID 702 , the status 706 being 
monitored, and the monitoring client SPID 704 of the subscriber who will receive 
the status updates of the monitored client. 

Once client database 328 and TCP/IP information database 326 includes 
the appropriate identifiers assigned to each new party to be monitored, registration 
service 314 sends an indication to monitoring client telephone 206 that the parties 
agreed to be monitored and are registered at central server 204. It will be 
appreciated that a number of methods exist to update monitoring client telephone 
206 with the SPEDs of the parties that will be monitored. For example, in one 
method, central server 204, in response to a request from monitoring client 
telephone 206, remotely updates monitored client database 334 with the SPIDs 602 
and the corresponding monitored client names 604. In an alternative method, the 
subscriber locally inputs monitored client SPEDs 602, and corresponding 
monitored client names 604 into monitored client database 334. 

Referring now to FIG. 1 1, a notification process 1 100 performed by 
notification service 316 of central server 204 may be better appreciated. Once 
registration service 314 registers the monitoring and monitored parties, monitored 
client telephone 202 automatically sends status updates via central server 204 to 
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the subscriber of monitoring client telephone 206. Monitored client telephone 202 
sends each status update in a TCP/IP packet when its status changes. 

It will be appreciated that the status change may be a DTMF code entered 
by the monitored party into monitored client telephone 202. For example, a party 
when working may enter a DTMF code. It will also be appreciated that when a 
first monitored party initiates a call to a second monitored party, monitored client 
telephone 202 of the first monitored party will submit status updates of both parties 
to central server 204. Furthermore, the status update may show that the first 
monitored party is electronically connected to the second monitored party. 

Prior to sending a packet of status updates, monitored client telephone 202 
uses a public key of central server 204 to encrypt and provide a digital signature 
within the TCP/IP packet. In step 1 102, notification service 316 of central server 
204 receives the encrypted TCP/IP packet from monitored client telephone 202. 
Notification 316 service uses the private key to decrypt and verify the packet's 
digital signature. Notification service 316 also compares the SPED and TCP/IP 
address information provider in the header portion of the TCP/IP packet to the 
appropriate entry in the TCP/IP database 326 to verify the source of the status 
update. Once the source of the update is verified, notification service 316 stores 
the status to current status 708 of the appropriate record(s). 

In step 1 104, notification service 316 queries client database 328 to retrieve 
a record that includes monitored client telephone 202. In step 1 106, notification 
service 316 determines if this record applies to the status update it received. More 
specifically, it determines if this status update corresponds to the status information 
that monitoring client telephone 206 is configured to receive. If the status 
corresponds, in step 1110, notification service 316 transmits the TCP/IP packet to 
queue manager 320. If the status does not correspond, in step 1 108, notification 
service 316 determines if there is another record corresponding to monitored client 
telephone 202. If there is another record, notification service 316 determines if this 
record applies to the status update it received from monitored client telephone 202. 
It will be appreciated that this process continues until notification service 316 
reviews all records of client database 328 that apply to monitored client telephone 
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202. Once the review of client database 328 records is completed, in step 1112, 
notification process 1 100 ends. 

Referring now to FIG. 12, a queuing process 1200 performed by queue 



manager 320 of central server 204 may be better appreciated. The process begins 
in step 1202 when queue manager 320 receives a TCP/IP packet from notification 
service 316. This packet includes a status update, and an origin and a destination 
SPED of respective monitored client telephone 202 and monitoring client telephone 
206. In step 1204, queue manager 320 retrieves from TCP/IP address database 326 
the TCP/IP address of monitoring client telephone 206 that corresponds to the 
destination SPID. In step 1206, queue manager 320 transmits the TCP/IP packet to 
the TCP/IP address of the appropriate monitoring client telephone 206. In step 
1208, if monitoring client telephone 206 successfully received the TCP/IP packet, 
queue manager 320 receives an acknowledgment of the successful transmission. 
Queue manager 320 updates client database 328 for billing purposes and drops the 
session with monitoring client telephone 206. 

It will be appreciated that all communications between central server 204 
and each client may be encrypted. For example, the TCP/IP information that 
monitoring client telephone 206 receives is encrypted. Monitoring client telephone 
206 uses its private key to decrypt and access the status update provided in the 
TCP/IP packet. Of course, one of ordinary skill in the art will understand that the 
communications do not necessarily have to be encrypted. Monitoring client 
telephone 206 updates monitored client database 334 with the status update. 
Display manager 412 of monitoring client telephone 206 displays the status update 
on display device 402. Accordingly, the subscriber of monitoring client telephone 
206 is capable of monitoring the status of the parties of monitored client telephones 
202 without even picking up the telephone. 

Referring now to FIG. 13, an embodiment of client digital phone 400 may 
be better appreciated. As shown, client digital phone 400 includes a handset 1302, 
an LCD display 1304, DTMF buttons 1306, extension status indicators 1308 and a 
volume control 1310. The screen of sample LCD display 1304 shows the current 
status of the parties of monitored client telephones 202. One of ordinary skill in 
the art will recognize that the four parties shown on LCD display 1304 are purely 
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illustrative of the status information provided to subscribers, and that any number 
of parties of monitored client telephones 202 may be displayed. If the number of 
monitored parties requires more display space than is available on LCD display 
1304, the status entries may continuously scroll. Alternatively, client telephone 
400 may include scrolling buttons, that allow a subscriber to scroll though pages of 
client digital phones 400 that are being monitored. 

It will be appreciated that an alternative embodiment of the present 
invention may utilize the Internet and other networks to transfer status information 
of a pre-selected list of frequently called telephone numbers from central server 
204 of the central service to the party of monitoring client telephone 206. In this 
embodiment, central server 204 receives status information as described above, but 
instead of sending the information to monitoring client telephone 206, central 
server 204 posts the status information to, e.g., the monitoring party's web page 
account. 

One of ordinary skill in the art will recognize that central server 204 may 
comprise a plurality of devices that are located in numerous geographical regions. 
Such devices would communicate with each other for the purpose of transmitting 
status update packets between different geographic regions. Accordingly, each 
device includes in its client database, records of all monitored and monitoring 
clients from all regions. When a device is notified of a status change of a 
monitored party, it transmits the status update packet to the device servicing the 
region where the monitoring party is located. In one embodiment for the present 
invention, each local region may include one device. 

It will be appreciated that unique separate servers may support each region 
by communicating with each other. It will be further appreciated that a single 
server may support multiple regions or may be distributed across multiple regions. 

A variety of different statuses, and uses of statuses, are consistent with the 
present disclosure. For example, a status may indicate who the monitored party is 
communicating with. In one embodiment, the central server could readily 
determine who the monitored party was communicating with, and make that 
information available to authorized monitoring parties. 
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A status may indicate who the monitored party is located near. As 
described herein, the location or approximate location of a phone may be 
determined. Accordingly, it may be determined which phones are located near the 
monitored phone. Such a status would be advantageous to, for example, a parent 
monitoring a child. 

A status may indicate the state of the battery of a battery-powered phone. 
Such a status would be advantageous in allowing a monitoring party to determine 
whether a call to the monitored party would unduly deplete the battery of the 
monitored party. 

A status may indicate the local time of the monitored party. For example, a 
monitored party may have traveled to a different time zone, and monitoring party 
can be informed of the local time of the monitored party. Such information would 
allow a monitoring party to exercise judgment as to whether it would be an 
appropriate time to call the monitored party. Such a status may also be used by the 
monitored party to block certain calls, for example, all calls after 1 1 :00 PM of the 
local time of the monitored party. 

A status may indicate whether the monitored party is using a text 
messaging or similar feature of a phone, such as a wireless phone with text 
messaging or email capability. Such a status may indicate, e.g., whether a 
monitored party is (i) available for text messaging, (ii) currently entering text, (iii) 
currently reading text, (iv) scrolling, and / or (v) playing online games or engaging 
in other online activity. 

A status may indicate whether the monitored party wants top receive calls, 
or when th\monitored party would like to receive calls. Such a capability may be 
extended onlySo certain kinds of calls. For example, the monitored party may 
desire to receive \ca\\ from customer service, or a call indicating a desired weather 
report or news reporL 

In one embodiment, the status information may trigger a message sent to 
the monitoring party. Such a message may be via email, instant messaging, audio 
or other means. 

Status information need not be displayed, or might be displayed in 
conjunction with other types of output of status information. For example, status 
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information could be output through the speaker on the phone, another speaker or 
other audio device. Thus, status may be output as messages such as "Bill is 
working right now", "Bill's is in New York and the local time is midnight", or 
"Bill's battery is low. Please use your judgment whether you should call him 
now." 

Status information may also be indicated by a busy signal, or a different 
kind of busy signal than is normally output. Different busy signals may be used 
for different statuses. The selection of busy signals used for different statuses may 
be selected by the monitoring party and / or the monitored party. 

A status may indicate whether the monitored party is moving, the speed and 
/ or the direction of movement. For example, the location of a car phone or 
cellular phone may be periodically determined, and thus a changing location can 
indicate that the monitored party is moving. Additionally, the speed and direction 
of movement can likewise be easily determined. It may be desirable to "block" 
calls when in moving. It may also be desirable to prevent outgoing calls while in 
motion. Similarly, it may be advantageous to require an override code to be 
entered into a phone while in motion in order to permit an outgoing call. For 
example, a state law may prohibit talking on a phone while driving a car. 

The particular patterns of status changes may be learned. For example, if a 
certain location is established as having a status during certain times, or a certain 
status is periodically established during certain times of the day, these patterns may 
be learned by appropriate machine learning techniques, as is well understood by 
those skilled in the art. Thus, the party may be able to avoid manually entering 
status information and other information if the requisite pattern has been learned. 
Similarly, once the pattern has been learned, the future status at certain times may 
be predicted. Messages and other information may be adapted to this prediction. 
For example, if it is learned that a status of unavailable occurs every work day 
between 2:00 PM and 3:00 PM then a calling party calling at 2:30 PM may be 
informed that the called party will become available at 3:00 PM. 

An additional status may be that the phone has detected a noise, or a noise 
exceeding a certain decibel level, at any time or while its status was a 
predetermined status, such as "nobody home". Such an embodiment would be 
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advantageous for monitoring a home while it is vacant. Detecting a noise could 
trigger, e.g., a call to a predetermined number (such as a work number) and could 
also play back during that call the previous thirty seconds of sound recorded prior 
to the detected noise. 

Another type of remote monitoring would be to permit information from 
the phone to be transmitted to another location. For example, a log of calls made 
to the phone in the last four hours may be transmitted (e.g., via fax, email, over the 
phone) when a code is received (e.g., via a work phone, via email). Additionally, 
after receiving such a log, a party could indicate which calls he wanted to return 
(e.g., upon arriving back home). In one embodiment such calls may be returned 
without dialing; the order of returned calls could be established when indicating 
which calls to return, and the calls made by merely picking up the phone 
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